-
Notifications
You must be signed in to change notification settings - Fork 12
Conversation
Check if the spk already exists. If yes, returns false, or else add the spk into map and returns true
1a54df7
to
6a39119
Compare
Codecov Report
@@ Coverage Diff @@
## master #118 +/- ##
=======================================
Coverage 59.39% 59.39%
=======================================
Files 8 8
Lines 266 266
=======================================
Hits 158 158
Misses 108 108
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Thaks @rajarshimaitra. Shall we also change the name to |
fb77897
to
f7cc15e
Compare
f7cc15e
to
6fb1738
Compare
Done.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK 6a39119
I like how this is looking.
bdk_chain/src/lib.rs
Outdated
@@ -37,13 +37,15 @@ pub mod collections { | |||
#![allow(dead_code)] | |||
pub type HashSet<K> = alloc::collections::BTreeSet<K>; | |||
pub type HashMap<K, V> = alloc::collections::BTreeMap<K, V>; | |||
pub use alloc::collections::btree_map::Entry; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why though.. We can, but then we need to specify which::Entry
at call site and feature gate it.. Not creating feature gated collection imports is what this module was intended to solve.. But maybe I am missing something.. Do you have a better way to call entry without explicit import?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If someone wants to import both bdk_core::collections::Entry
(which is only a btree_map::Entry
) and std::collections::hash_map::Entry
at the same time, it will get messy. I think having to explicitly state which Entry
it is, is a good-to-have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm.. I think I am getting what you are saying.. I tried it out but unfortunately this particular Entry
itself will have three variants depending on feature list.. And different parent modules are available with different features.. So there's no way to do it without different feature gating combination at each module we wanna call Entry
in.. It seems to me this way of consolidating all required imports is better than having various feature gates in different modules.. If later on we want to use both kinda Entry
together we can explicitly import and give different names to them here in collections
module. like use::std::collections::btree_map::Entry as StdBtreeEntry
or something like that..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can make hash_brown
a non-optional dependency if that helps.
bdk_chain/src/lib.rs
Outdated
pub use alloc::collections::*; | ||
} | ||
|
||
// When we have std use `std`'s all collections | ||
#[cfg(all(feature = "std", not(feature = "hashbrown")))] | ||
#[doc(hidden)] | ||
pub mod collections { | ||
pub use std::collections::hash_map::Entry; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think this should be removed.
bdk_chain/src/lib.rs
Outdated
@@ -55,4 +57,5 @@ pub mod collections { | |||
pub type HashSet<K> = hashbrown::HashSet<K>; | |||
pub type HashMap<K, V> = hashbrown::HashMap<K, V>; | |||
pub use alloc::collections::*; | |||
pub use hashbrown::hash_map::Entry; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pub use hashbrown::hash_map::Entry; | |
pub use hashbrown::hash_map; |
I think this would make more sense, then the above two lines can be removed and everything will be consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What exactly are you referring as inconsistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant that you can remove the two lines above without resulting in inconsistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing as here #118
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Just need to sort out the Entry
export thing. I think you can just export the hash_map
module from each thing and import it has collections::hash_map::Entry?
bdk_chain/src/lib.rs
Outdated
@@ -37,13 +37,15 @@ pub mod collections { | |||
#![allow(dead_code)] | |||
pub type HashSet<K> = alloc::collections::BTreeSet<K>; | |||
pub type HashMap<K, V> = alloc::collections::BTreeMap<K, V>; | |||
pub use alloc::collections::btree_map::Entry; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can make hash_brown
a non-optional dependency if that helps.
Import `hash_map` module from each category and call `collections::hash_map::Entry` at call site. plus some nit fixes.
@LLFourn updated as suggestied. Let me know if this is how you meant to import..
Could be, but what we have currently doesn't seem to be bad either.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 46524ad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Check if the spk already exists. If yes, returns false, or else add the spk into map and returns true
Fixes #98